The present invention relates to a computer system, and deals more particularly with a method, system, and computer-readable code for delegating authentication and authority from a client to a server in order that the server can establish a secure connection (using SSL or an analogous security protocol) to a back-end application on behalf of the client.
Secure Sockets Layer, or xe2x80x9cSSLxe2x80x9d, is a networking protocol developed by Netscape Communications Corp. and RSA Data Security, Inc. to enable secure network communications in a non-secure environment. More particularly, SSL is designed to be used in the Internet environment, where it operates as a protocol layer above the TCP/IP (Transmission Control Protocol/Internet Protocol) layers. The application code then resides above SSL in the networking protocol stack. After an application (such as a browser) creates data to be sent to a peer in the network, the data is passed to the SSL layer where various security procedures are performed on it, and the SSL layer then passes the transformed data on to the TCP layer. On the receiver""s side of the connection, after the TCP layer receives incoming data it passes that data upward to the SSL layer where procedures are performed to restore the data to its original form, and that restored data is then passed to the receiving application. The most recent version of SSL is described in detail in xe2x80x9cThe SSL Protocol, Version 3.0xe2x80x9d, dated Nov. 18, 1996 and available on the World Wide Web (xe2x80x9cWebxe2x80x9d) at http://home.netscape.com/eng/ssl3/draft302.txt (hereinafter, xe2x80x9cSSL specificationxe2x80x9d).
The protocols underlying the Internet (TCP/IP, for example) were not designed to provide secure data transmission. The Internet was originally designed with the academic and scientific communities in mind, and it was assumed that users of the network would be working in non-adversarial, cooperative manners. As the Internet began to expand into a public network, usage outside these communities was relatively limited, with most of the new users located in large corporations. These corporations had the computing facilities to protect their user""s data with various security procedures, such as firewalls, that did not require security to be built into the Internet itself. In the past several years, however, Internet usage has skyrocketed. Millions of people now use the Internet and the Web on a regular basis. (Hereinafter, the terms xe2x80x9cInternetxe2x80x9d and xe2x80x9cWebxe2x80x9d are used synonymously unless otherwise indicated.) These users perform a wide variety of tasks, from exchanging electronic mail messages to searching for information to performing business transactions. These users may be accessing the Internet from home, from their cellular phone, or from a number of other environments where security procedures are not commonly available. To support the growth of the Internet as a viable place to do business, often referred to as xe2x80x9celectronic commercexe2x80x9d or simply xe2x80x9ce-commercexe2x80x9d, easily-accessible and inexpensive security procedures had to be developed. SSL is one popular solution, and is commonly used with applications that send and receive data using the HyperText Transfer Protocol (xe2x80x9cHTTPxe2x80x9d). HTTP is the protocol most commonly used for accessing that portion of the Internet referred to as the Web. When HTTP is used with SSL to provide secure communications, the combination is referred to as xe2x80x9cHTTPSxe2x80x9d. Non-commercial Internet traffic can also benefit from the security SSL provides. SSL has been proposed for use with data transfer protocols other than HTTP, such as Simple Mail Transfer Protocol (xe2x80x9cSMTPxe2x80x9d) and Network News Transfer Protocol (xe2x80x9cNNTPxe2x80x9d).
SSL is designed to provide several different but complementary types of security. First is message privacy. Privacy refers to protecting message content from being readable by persons other than the sender and the intended receiver(s). Privacy is provided by using cryptography to encrypt and decrypt messages. SSL uses asymmetric cryptography, also known as public-key cryptography. A message receiver can only decrypt an encrypted message if he has the proper private key and decryption algorithm that are associated with the message creator""s public key. Second, SSL provides data integrity for messages being transmitted. Data integrity refers to the ability for a message recipient to detect whether the message content was altered after its creation (thus rendering the message untrustworthy). A message creator passes the message through an algorithm which creates what is called a xe2x80x9cmessage digestxe2x80x9d, or xe2x80x9cmessage authentication codexe2x80x9d. This digest is sent along with the message. When the message is received, the receiver also processes the message through an algorithm, creating another digest. If the digest computed by the receiver does not match the digest sent with the message, then it can be assumed that the message contents were altered in some way after the message was created. The third security feature SSL provides is known as authentication. Communications over the Internet take place as a sequence of electronic signals, without the communicating parties being able to see each other and visually determine with whom they are communicating. Authentication is a technique that helps to ensure that the parties are who they represent themselves to bexe2x80x94whether the party is a human user or an application program. For example, if a human user is buying goods over the Internet using a credit card, it is important for him to know that the application waiting on the other end of the connection for his credit card information is really the vendor he believes he is doing business with, and not an impostor waiting to steal his credit card information.
These security features are very powerful, and provide a high degree of protection for Internet users. However, SSL was designed as a two-party protocol, to be used in a client/server environment. The SSL protocol provides for a client to request a secure communication session by sending a message to a server application. The server then responds, and a sequence of messages are exchanged in a handshaking protocol where the various security-related parameters are negotiated. The encryption algorithms to be used for message privacy and data integrity are agreed upon, and both the client and server may authenticate each other""s identity. (SSL also provides modes where the client and server are not authenticated, but those modes are not pertinent to the present discussion.) Authentication is performed during the handshake by exchanging digital certificates. (Digital certificates will be discussed in more detail below.) The server sends its certificate to the client, enabling the client to authenticate the server""s identity. The server then requests the client""s certificate, which the client sends in order that the server can also authenticate the client""s. identity. If the authentication results are acceptable, the parties complete the handshake, and begin to exchange encrypted application data over the secure session they have established.
The client-server model for network computing is being extended in the Web environment to what is referred to as a xe2x80x9cthree-tier architecturexe2x80x9d. This architecture places the Web server in the middle tier, where the added third tier typically represents a back-end legacy application, or data repositories of information that may be accessed by the Web server as part of the task of processing the client""s request. This three-tiered architecture recognizes the fact that many client requests do not simply require the location and return of static data by the Web server, but require an application program to perform processing of the client""s request in order to dynamically create and format the data to be returned. In this architecture, the Web server may be referred to as an xe2x80x9capplication serverxe2x80x9d, or xe2x80x9cmiddle-tier serverxe2x80x9d. For example, a human user interacting with a Web browser on his computer may access a transaction server such as CICS(copyright) by sending a CICS request to a Web server, where this request is then forwarded from the Web server on to the CICS server. (xe2x80x9cCICSxe2x80x9d is a registered trademark of the International Business Machines Corporation, hereinafter xe2x80x9cIBMxe2x80x9d.) The CICS server processes the request, and sends a response back to the Web server, which then forwards the response back to the client software in the user""s browser. The Web server acts as the middle-tier server (xe2x80x9cMTSxe2x80x9d), while the CICS server acts as an xe2x80x9cend-tierxe2x80x9d server (xe2x80x9cETSxe2x80x9d). Other types of back-end legacy applications, such as relational database management systems, may be accessed using this approach as well.
SSL may be used to establish a secure session between the client and the MTS. Because SSL is strictly a two-party protocol, however, there is currently no way to extend this secure session into the three-tiered environment. The client authentication process within SSL is designed such that the client digitally signs data that it derives from the server""s (i.e. the MTS""s) certificate during the handshaking protocol. This digital signature requires the client to use its private key for encryption, and to send the resulting signature back to the MTS along with the client""s certificate. The client""s private key must never leave the client machine, or it would no longer meet the requirements for a private key. Thus, the MTS cannot create a digital signature on behalf of the client, because the MTS cannot learn the client""s private key. Other existing techniques are equally unsatisfactory: if the MTS were to send the client""s request to the ETS over a non-secure connection, then the security of the client""s data would be compromised. If the MTS established a second SSL session between itself and the ETS (using existing techniques) and sent the client""s request in that session, the ETS would be unable to determine the true identity of the party for whom it was performing the transaction. This is because the SSL code in the servers reports the name of its peer to the application program on that server for which SSL is being used. Thus, the SSL code in the ETS will report to its application that its peer is the MTS. If the MTS services thousands of clients, for example, the ETS would view them all as being the same client: the MTS, which is the only peer the ETS knows about. Many ETSs will execute applications that require access control checks to be performed, whereby a list of authorized users (not to be confused with authenticated users) is used to limit access to information and services. Access logs may also be used, where the application records identifying information for each user of the application""s information or services. In such situations, it is necessary to know the identity of the true clientxe2x80x94that is, the client in the first tier. There may be many situations other than access control where the true client identity is needed, where the requirement for knowing the identity may or may not be related to security concerns.
One technique by which a client/server session can be authenticated is to use the Kerberos network authentication protocol, which was developed by Massachusetts Institute of Technology. Kerberos provides techniques for delegating authentication, but it is based on the use of secret-key (or private key) cryptography, with keys that are stored in an escrow system. Section 1.0 of the SSL specification states that public-key cryptography will be used for authentication, thus ruling out Kerberos as a viable approach for extending SSL.
Accordingly, a need exists for a technique for extending SSL into the three-tier architecture in a manner that allows the true client""s identity to be known to the ETS. The present invention provides several alternative solutions to this problem, whereby the client delegates authority and authentication to the MTS in order that the MTS can establish a second SSL session to the ETS on behalf of this client.
An object of the present invention is to provide a technique whereby SSL can be extended into the three-tier architecture in a manner that allows the true client""s identity to be known to the ETS.
Another object of the present invention is to provide this technique by delegating authority and authentication from the client to the MTS.
It is an object of the present invention to provide several alternative embodiments for a solution to this delegation process.
Still another object of the present invention is to provide a technique whereby digitally signed documents are used to enable this delegation to occur.
It is another object of the present invention to provide a technique whereby X.509 certificates are used to enable this delegation to occur.
A further object of the present invention is to provide a technique whereby the MTS involves the client in the handshaking process with the ETS.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a software-implemented process for use in a computing environment having a connection to a network, for delegating authority and authentication from a client to a middle-tier server (MTS). This computer-readable code, system, or method comprises: establishing a first secure session between a client security implementation operating at the client, the client also having a client application operating therein, and an MTS security implementation operating at the MTS, the MTS also having an MTS application operating therein; and establishing a second secure session between the MTS security implementation and an end-tier security implementation operating at an end-tier server (ETS), the ETS also having an ETS application operating therein, wherein the MTS security implementation establishes the second secure session on behalf of an identity of the client application.
In one aspect, establishing the second secure session further comprises: in the MTS security implementation, requesting an X.509 delegate certificate from the client security implementation; in the client security implementation, responsive to the request from the MTS security implementation, creating the X.509 delegate certificate and sending the created delegate certificate to the MTS security implementation; in the MTS security implementation, receiving the delegate certificate sent from the client security implementation and forwarding the received delegate certificate to the end-tier security implementation along with a certificate for the client; and in the end-tier security implementation, extracting a subject identity from the forwarded delegate certificate, wherein the extracted identity is the identity of the client application.
In another aspect, establishing the second secure session further comprises: in the MTS security implementation, requesting an X.509 delegate certificate from the client security implementation; in the client security implementation, responsive to the request from the MTS security implementation, creating the X.509 delegate certificate and sending the created delegate certificate to the MTS security implementation; in the MTS security implementation, receiving the delegate certificate sent from the client security implementation and forwarding the received delegate certificate to the end-tier security implementation along with a certificate and a certificate hierarchy for the client; and in the end-tier security implementation, extracting a subject identity from the forwarded certificate hierarchy, wherein the extracted subject identity is the identity of the client application.
In yet another aspect, establishing the second secure session further comprises: in the MTS security implementation, requesting a signed delegate document from the client security implementation; in the client security implementation, responsive to the request from the MTS security implementation, creating the signed delegate document and sending the created delegate document to the MTS security implementation; in the MTS security implementation, receiving the delegate document sent from the client security implementation and forwarding the received delegate document to the end-tier security implementation along with a certificate for the MTS; and in the end-tier security implementation, extracting a subject identity from the forwarded delegate document, wherein the extracted subject identity is the identity of the client application.
In still another aspect, establishing the second secure session further comprises: in the MTS security implementation, requesting a signed delegate document from the client security implementation; in the client security implementation, responsive to the request from the MTS security implementation, creating the signed delegate document and sending the created delegate document to the MTS security implementation; in the MTS security implementation, receiving the delegate document sent from the client security implementation; in the MTS security implementation, receiving a certificate request from the end-tier security implementation and forwarding a further certificate request to the client security implementation wherein the further certificate request contains an identification of the end-tier application; in the client security implementation, responsive to the further certificate request from the MTS security implementation, creating a further signed delegate document based on the identification of the end-tier application, and wherein the further signed delegate document specifies the identification, and sending the created further delegate document to the MTS security implementation; in the MTS security implementation, receiving the further delegate document sent from the client security implementation and forwarding the received further delegate document to the end-tier security implementation along with a certificate for the MTS; and in the end-tier security implementation, extracting a subject identity and the identification from the forwarded further delegate document, wherein the extracted subject identity is the identity of the client application, and verifying that the extracted identification is an identification of the extracting end-tier security implementation.
In another aspect, establishing the second secure session further comprises: in the MTS security implementation, receiving a certificate request from the end-tier security implementation; in the MTS security implementation, receiving the certificate request and forwarding a further certificate request to the client security implementation wherein the further certificate request comprises a collection of handshaking data received from the end-tier security implementation; in the client security implementation, responsive to the further certificate request from the MTS security implementation and based upon an identification of the end-tier application extracted from the handshaking data, creating a digital signature and sending the digital signature embedded in a message to the MTS security implementation; in the MTS security implementation, receiving the message sent from the client security implementation, extracting the digital signature, and forwarding the extracted digital signature to the end-tier security implementation along with a certificate for the client; and in the end-tier security implementation, extracting the identity of the client application from the forwarded certificate for the client.
In yet another aspect, establishing the second secure session further comprises: in the MTS security implementation, receiving a certificate request from the end-tier security implementation; in the MTS security implementation, responsive to receiving the certificate request, extracting a name of the client application from a client certificate receiving during the first secure session establishment; in the MTS security implementation, creating a temporary public key, private key pair for representing the client application; in the MTS security implementation, creating an X.509 delegate certificate, the created delegate certificate comprising the extracted name and the temporary public key; in the MTS security implementation, forwarding the created delegate certificate to the end-tier security implementation along with a digital signature created by the MTS security implementation using the temporary private key; and in the end-tier security implementation, extracting a subject identity from the forwarded delegate certificate, wherein the extracted identity is the identity of the client application. This aspect may further comprise in the MTS security implementation, storing the created key pair and the created delegate certificate for use with any subsequent first secure sessions between the client security implementation and the MTS security implementation.
Preferably, the client security implementation, MTS security implementation, and end-tier security implementation will use a Secure Sockets Layer protocol or a Transaction Layer Security protocol.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.